Information-Centric Networking (ICN) is a new networking paradigm with the goal of evolving the current Internet infrastructure away from a host-oriented system towards a data-oriented system. Instead of addressing endpoints via IP addresses, data itself is addressed in ICN. By dividing data into chunks, and giving each of those chunks a unique and hierarchical name, ICN allows clients to ask the network for a given named data object, without having to worry where that data is located/stored. One of the benefits of naming data is that each intermediate network node, such as a switch or a router, has the ability to cache the data packets that flow through it. In this way, if a new consumer requests data which is already cached in the network, its request does not need to travel through the network towards the original producer of the data, but can instead be served by one of the intermediate network nodes holding a copy of that data.
Current ICN architectures have two elementary types of messages at their core: interest messages and data messages. When an application wants to retrieve a particular data object, it sends out an interest message for that data object. The most important part of this interest message is the name of the object, or, in cases where the full name of the object is not known, a prefix.
An example of such an ICN architecture is Named Data Networking (NDN) described in “Named data networking”, Zhang et al., ACM SIGCOMM Computer Communication Review 44 Issue 3, July 2014, pages 66-73. When a network node receives an interest message in NDN, it first checks whether its local cache happens to contain a named data object that matches the name in the interest message. If a corresponding named data object is found, it is wrapped in a data message and sent back over the interface over which the interest message was received.
In the case where the object is not cached, the next step is to check whether the requested name is already in the so-called Pending Interest Table (PIT). The PIT maintains a list of existing, pending data object requests and the corresponding interfaces through which they were requested. When a data message comes in, it is forwarded to all interfaces that according to the PIT have an unsatisfied interest for the corresponding name. The entry in the PIT is then deleted. When a name in an incoming interest message is not listed in the PIT, it is added along with the interface over which it was received. The interest message is then forwarded on one or more outgoing interfaces according to the Forwarding Information Base (FIB) and the Strategy layer, in search of the requested data at another node.
Caching in ICN has the potential of decreasing the latency experienced by the consumer while reducing network traffic at the same time. However, since any node on the path from the source of content (which may be an intermediate caching node or the original producer) to the consumer can cache content, managing the caching decisions of caching nodes becomes crucial to avoid inefficient usage of such in-network caching capacity and suboptimal performance in terms of traffic and latency. Important caching decisions that need to be carefully managed are: 1. which data item should a specific cache store, and 2. if the cache storage is full, which data item should be replaced.
It appears evident that inefficient caching decisions are more likely to happen when nodes make such decisions independently from each other, based solely on “local” information (i.e. information available at each caching node itself, such as the items being requested, the items being cached, the frequency of requests, etc.), which is the standard approach in ICN. However, it becomes necessary to consider some level of the “global” picture (e.g. is the newly received item already cached in a neighbouring cache? is the data that a cache currently stores more popular than a newly received item?) to make efficient caching decisions in an Information-Centric Network.
“Age-based cooperative caching in information-centric networking”, Zhongxing Ming, Mingwei Xu, and Dan Wang, 23rd International Conference on Computer Communication and Networks, 2014, published by IEEE, discloses a method in which items are stored in a cache along with an age field that indicates an expiry time. When the expiry time lapses, the item is replaced by another item. The value of the age field stored along with the item in the cache is based on an age field in the received data message that comprises the item. The age of an item is set by the first node along the path based on the popularity of the item. Each subsequent node along the path increases (e.g. doubles) the age in the data message before forwarding the data message. The result is that caches at the edge comprise mostly popular items, while caches further away from the edge also comprise less popular items. An advantage of this method is that it does not require (separate) signalling messages between routers.
A drawback of this method is that the caches are not used efficiently, because certain popular items are likely cached both at the edge and at one or more nodes further away from the edge, while certain less popular items are likely not cached at all.
The use of caches is also known in other types of networks, since it is advantageous to use caches for preventing that each request needs to travel through a complete network to a server that can handle the request. Popular content is often stored in a cache to save bandwidth, reduce server load and improve client response times.
For example, Network Service Providers (NSP) may use caching proxies in their networks to more efficiently utilize their networks. A caching proxy is a proxy server which is able to cache content and act as an intermediate network node for HTTP requests and responses. For example, in case of a content network, multiple caching proxies may reside on various points between a User Agent (UA) and a Content Service Provider (CSP). The major difference is, that within the context of ICN the data is addressed while in HTTP the location of data is addressed.
Since both HTTP requests and responses flow through these caching proxies, each server decides for itself whether to cache the requested data object or not. This decision may be based upon local policies. A caching proxy may decide for example only to cache popular heavily requested items or evaluate HTTP headers to choose whether or not to cache the content.
A drawback of caching proxies is that each server decides for itself whether or not to store a data object, often resulting in popular content being stored in multiple caching proxies between e.g. the User Agent (UA) and the Content Service Provider (CSP) and less requested content not being stored at all, hence making an inefficient use of the available caching capacity.